The current version
of the Silicon
Graphics, Inc. (SGI) X server [11] supports both standards
for 3D graphics for the X Window System: the OpenGL
graphics system [16,15,14] and PEX 5.1
[20]. OpenGL is an Application Programming Interface (API) for
3D interactive graphics developed by SGI and now administered by the
OpenGL Architecture Review Board. OpenGL is the successor to the
proprietary IRIS GL graphics interface (the GL stands for graphics
library). OpenGL supports the X Window System via the GLX extension
[10]. PEX is an X protocol extension developed by the X
Consortium to support 3D graphics for X. PEX's rendering functionality
and style are largely influenced by the PHIGS and PHIGS PLUS 3D
graphics standards [3].
Both extensions create interactivity problems for single-threaded X servers because both OpenGL and PEX requests can take substantial amounts of time to complete. Most X servers based on the X Consortium's sample server dispatch one request at a time and execute each request to completion. This works quite well for the core X protocol since most requests are completed in mere fractions of a second. When requests take a few milliseconds or less to execute, the X server can dispatch requests from all active clients fast enough to create an appearance of simultaneous execution and the user perceives the X server as being both interactive and fair to the clients using it.
But OpenGL and PEX can easily generate requests with arbitrarily long execution times. Even common requests can take several seconds to execute. For an X server that dispatches requests serially and each to completion, the result is an extremely non-interactive X server. Users perceive such X servers as sluggish and difficult to interact with.
The problem is not unique to OpenGL and PEX. Any extension with requests that take considerably more time to execute than the typical core X request can cause interactivity problems for an X server that executes one request at a time to completion.
This paper describes a solution to the interactivity problem named multi-rendering used to implement OpenGL and PEX in the Silicon Graphics X server. Multi-rendering involves creating separate threads of execution for rendering inside the X server's address space. These separate threads only interact with the X server's main thread during thread initialization and destruction, when locking a shared memory pool, and to communicate requests to execute and request completion status. Otherwise multi-rendering threads never touch X server data structures such as the window tree and never call core X rendering routines. The main X server thread continues to perform all core X request dispatching and rendering. The rendering threads render directly to the hardware making use of virtualized direct access to avoid needing knowledge of window origins or clip regions.
The IRIX operating system's process share group facility, user-level and pollable semaphores, and support for virtualized direct access rendering provide sufficient machinery to implement multi-rendering. The only performance overhead introduced for core X request execution is very inexpensive memory pool locking. OpenGL and PEX requests are executed without compromising the interactivity of the X server.
The next section describes the goals and requirements for our multi-rendering implementation. The third section considers other approaches to solve the interactivity problem. The fourth section describes operating system facilities used to support multi-rendering. The fifth section details how multi-rendering is implemented in the our X server. The sixth section presents a performance analysis of multi-rendering support.